petitcomputerfandomcom-20200214-history
Talk:VSYNC vs WAIT/@comment-5334617-20141209183434
Flickering depends on the relative locations of the clear screen, draw screen, and sync operations, which you have not discussed or taken into account (and indeed the draw screen operation isn't in either of the last two code fragments). My understanding is that WAIT n'' will wait from 'now', when the system sees the WAIT command, until the ''n''th following 'tick' of the frame clock. If 'now' is just before a tick, WAIT 1 will not wait long at all. If 'now' is just after a tick, WAIT 1 will wait almost a full 1/60th of a second. VSYNC ''n, however, will wait until the n''th tick following the last WAIT or VSYNC - and if the ''n''th tick has already passed, it waits no time at all. Another way of thinking about it is that the VSYNC clock is reset every time a WAIT or VSYNC command ends. The WAIT clock is reset at the beginning of that WAIT statement. If less than one frame passes between one and the next, they behave identically. If between one and two frames pass, then a WAIT clock would be one frame behind the VSYNC clock; if between two and three frames pass, then a WAIT clock would be two frames behind the VSYNC clock, etc.. Also, a WAIT is guaranteed to end exactly on a tick. If the 'deadline' set in a VSYNC is already passed, it will take no time at all, and so the time might be at any phase relative to the frame clock. So, WAIT is more likely to eliminate flicker, when used correctly. Of course, the downside is that WAIT n will always take at least as long as VSYNC n, and sometimes longer. VSYNC also makes it much easier to maintain a more consistent relationship between 'game time' (the number of iterations through your game's main loop) and 'wall time' (the number of ticks of the second hand on the clock on the wall) without having to use MAINCNTL and MAINCNTH. This is important if, for most of a game, you do less than one frame's worth of calculations per iteration, but during the climax, you do more than one frame of calculation, but you don't want the action to slow down. If you use WAIT 1, the refresh rate of the game will drop from 60 per second to 30 per second, but if you use VSYNC 2, and an iteration never takes more than 2 frames, you will have a consistent 30 refreshes per second throughout, and no flickering either (if clearing and drawing takes less than VBlank (see Discordstew's comment below) and is put right after the VSYNC). The double-buffering mentioned by DiscordStew is possible in PTC: see GPAGE. But that perhaps should have its own section. '''EDIT:' It seems my explanation and DiscordStew's are incompatible. What I have written is from memories of similar systems I have seen in the past, so may not be applicable to PTC. DiscordStew has more pertinent information regarding DS and DSi systems, so that could well be the more reliable source. I'll leave my comment for reference, and because I don't want to delete the work I put into writing it. :P